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A  White  Paper  the  Conceptual  Requirements  for  an  Operational  Airpower  Planning  Tool 


The  current  operational  Air  Tasking  Order  (ATO)  planning  tool,  Theater  Battle  Management 
Core  System  (TBMCS)  application  Theater  Air  Planner  (TAP),  is  approaching  obsolescence. 
This  application  runs  on  a  Uniplexed  Infonnation  and  Computing  System  (UNIX)  platform. 
Most  computers  in  the  Air  and  Space  Operations  Center  (AOC)  are  Windows/Intel-based  PCs. 
The  TAP  application  is  the  culmination  of  a  long  line  of  outstanding  computer  applications  that 
minimized  the  time  and  manpower  needed  to  create  the  United  States  Message  Text  Format 
(USMTF)  ATO  message.  We  must  now  posit  conceptual  requirements  for  the  next  generation 
Operation  Airpower  Planning  tool.  The  design  philosophies  to  achieve  the  capabilities  required 
of  the  Operation  Airpower  Planning  tool  and  the  USMTF  ATO  production  tool  are  diametrically 
opposed,  despite  their  essentially  identical  role  in  directing  assigned  tactical  forces. 

The  purpose  of  the  ATO  and  Air  Control  Order  (ACO),  as  defined  by  the  USMTF,  is  “The  ATO 
is  used  to  task  air  missions  and  assign  cross-force  tasking  and  may  also  be  used  for  intra-Service 
tasking,”  while  “The  ACO  is  used  to  provide  specific  detailed  orders  for  airspace  management 
from  a  higher  command  to  subordinate  units.”  To  clarify  our  goal  in  creating  the  next  generation 
Operational  Airpower  Planning  Tool,  we  must  understand  the  history  of  the  USMTF  ATO 
production  tool.  The  ATO  message  is  divided  into  two  sub-sets.  Mission  Data  Lines  (MSNDAT) 
and  Special  Operation  Instructions  (SPINS).  Traditionally,  the  AOC  staff  creates  MSNDAT  and 
Air  Force  Forces  (AFFOR)  staff  creates  the  information  required  for  SPINS.  Both  sets  of 
information  and  the  infonnation  in  the  ACO  message  are  required  to  execute  combat  air  power. 

Automated  building  of  the  ATO  message  started  with  a  Disk  Operating  System  program,  Frag 
Works,  which  ran  on  a  286  PC  in  the  early  1980s.  The  program  allowed  one  person  (generally  a 
clerk- typist)  to  fill  blank  fields  in  the  USMTF  message  (Today,  we  would  call  this  message  a 
text  or  flat  file).  A  group  of  experts  performed  all  planning  (including  sortie  deconfliction  and 
tanker  scheduling)  by  hand  calculation  or  using  another  stand-alone  computer  system.  Expert 
planners  would  hand  the  clerk-typist  sheets  of  information  to  type  into  message  format.  The 
operational  data  required  by  expert  planners  to  create  a  cogitative  plan  was  organized  on  grease 
boards  or  legal  paper.  The  operational  data  had  to  be  nearly  complete  before  experts  could  plan 
individual  ATO  mission  lines  to  be  handwritten  on  sheets  submitted  to  the  clerk-typist. 

The  next  evolutionary  leap  was  the  Contingency  Theater  Automated  Planning  System  (CTAPS). 
The  application  in  this  program  that  created  the  ATO  message  was  the  Computer  Assisted  Force 
Management  System  (CAFMS),  a  [Dumb]  Oracle  Database  networked  with  several  UNIX  client 
PCs.  All  mission  planning  was  still  by  hand  calculation  or  use  of  stand-alone  computer  systems. 
Information  was  written  on  worksheets,  passed  to  a  group  of  clerk-typists  (CAFMS  technicians), 
and  typed  into  database  fields  using  Sequel  Query  Language.  CAFMS  held  both  operational  and 
mission  planning  data.  It  allowed  Combat  Operations  to  retrieve,  sort,  and  manipulate  data  as 
required.  Any  data  that  complied  with  the  rules  governing  that  field  could  be  entered.  The  ATO 
was  printed  as  a  flat  file  of  data  from  the  CAFMS  database.  All  USMTF  message  fields  could  be 
retrieved  from  this  database.  The  expert  planner  reviewed  the  ATO  printout  to  ensure  data  was 
entered  correctly.  CAFMS  did  not  reduce  manpower  required  to  organize  and  coordinate  the 
essential  data,  but  it  did  substantially  decrease  time  required  to  type  the  ATO. 

The  next  generation  application,  Advanced  Planning  System  (APS),  “rode  on  top”  of  the  legacy 
CAFMS  data  structure  in  the  next  version  of  CTAPS.  APS  was  designed  to  initiate  data 


organization  and  expedite  creation  of  individual  mission  lines.  APS  was  a  [Smart]  database.  It 
incorporated  some  of  the  tools  used  in  the  standalone  computer  systems  and  reduced  the  need  for 
hand  calculations.  All  required  general  planning  data  was  entered  in  APS  fields  by  CAFMS 
technicians  to  create  an  APS  data  store  before  the  exercise  or  contingency.  The  data  included 
base  location,  aircraft  and  mission  type,  standard  convention  load,  fuel  burn  rate,  and  other  data. 
Large  groups  of  data  such  as  Airspace  individual  Air  Control  Measures  or  Intel’s  Target 
Nomination  List  were  imported  from  creating  organizations.  Hand  entry  and  import  of 
information  had  to  be  complete  before  multiple  expert  users  could  begin  to  type  the  thousands  of 
mission  lines  of  a  large  ATO.  An  APS  error  message  would  flag  the  operator  if  computer 
algorithms  recognized  a  conflict.  For  example,  the  error  message:  “Unflyable  Mission”  might 
prompt  the  user  to  review  the  planned  line  and  find  it  to  be  short  100  lbs.  of  fuel.  For  aircraft 
flying  8  hours  100  lbs  short  of  fuel,  an  operator  could  determine  the  “problem”  insignificant,  and 
override  the  computer.  APS  was  adept  at  pairing  fighters  and  tankers  and  determining 
appropriate  fuel  for  strike  missions.  It  did  straight  line  planning  for  each  mission  line  created.  Air 
mobility  command  elements  did  not  use  APS  to  plan  theater  and  strategic  airlift.  In  the  earliest 
version  of  APS,  certain  fields  could  not  be  overwritten  and  not  all  fields  in  the  USMTF  message 
could  be  automatically  filled  in  creating  the  ATO  message.  When  planners  completed  entry  into 
APS,  the  data  was  transferred  back  to  the  legacy  CAFMS  database.  The  ATO  message  went 
back  to  the  [dumb]  database  where  airlift  missions,  SPINS1  and  information  needed  to  fill  in 
other  fields  was  added.  The  final  ATO  message  produced  with  APS  was  still  a  USMTF  flat  file. 

The  APS  application  successfully  represented  data  and  constrained  use  of  resources  with  detailed 
data  models  that  combined  a  relational  database  with  a  volatile  knowledge  base  and  implemented 
business  rules  in  algorithms.  Some  of  its  behavior  models  were  pure  physics  (rate/time/distance) 
that  prevented  objects  from  attempting  to  occupy  the  same  space  at  the  same  time. 

The  sizeable  investment  in  APS  and  the  success  it  achieved  led  to  creation  of  TAP  based  on  the 
same  design  philosophy.  TAP  inherited  much  of  its  computer  code  and  many  input  screens  from 
APS.  It  incrementally  “fixed”  most  user  problems  associated  with  APS;  updated  the  year  group 
of  the  USMTF  message  created2;  and  implemented  time  and  ATO  production  manpower 
reduction  protocols. 

In  light  of  this  history,  it  is  clear  that  an  effective  Operational  Airpower  Planning  Tool  must  look 
beyond  the  design  philosophy  that  created  the  current  USMTF  planning  tool.  To  achieve 
leadership  goals,  we  need  a  planning  tool  that  can  be  used  by  most  AOC  crewmembers;  will 
store,  manipulate,  and  calculate  infonnation  required  by  their  duty  position;  and  is  scaleable, 
flexible,  and  easy  to  use  in  creating  output,  which  could  be  the  USMTF  ATO  message. 

TAP's  “twin”  application  in  the  Execution  Tools  Suite  is  the  Execution  Management  Replanner 
(EMR).  EMR  provides  a  common  look  and  feel  and  similar  data  models,  but  its  procedures  for 
synchronizing  databases  are  a  hindrance.  There  are  few  differences  between  TAP  and  EMR 
applications,  as  they  share  a  source  code  baseline  and  have  the  same  basic  architectural  design. 
Hence,  EMR  will  not  be  discussed  further,  except  this  caveat:  information  produced  by  an 
Operational  Air  Power  Planning  tool  should  allow  replanning  and  visualization  of  information  by 
Combat  Operations  and  external  organizations. 


1  SPINS  were  generally  compiled  in  a  word  processing  program  such  as  Microsoft  Word 

2  Every  2  years,  a  new  version  of  USMTF  messages  is  released  and  all  military  computer  systems  must  be  able  build 
and  use  the  newest  messages. 


The  first  critical  requirement  for  an  Operational  Air  Power  Planning  tool  is  scalability.  CTAPS 
and  TBMCS  are  not  scaleable  in  design.  The  TBMCS  design  and  testing  requirement  was  a 
worst-case  “cold  war”  scenario  that  created  an  ATO  to  execute  3000  missions  on  any  given  day. 
This  design  and  testing  criteria  worked  in  large-scale  exercises  and  in  both  Gulf  Wars.  TBMCS 
was  not  adaptable  to  situations  of  significantly  smaller  scope  with  considerably  less  manpower. 
Ingenious  “work-arounds”  were  continually  employed  by  organizations  engaged  in  combat  (e.g., 
Operations  Northern  and  Southern  Watch)  and  in  training  of  tactical  forces  (e.g.,  Red  Flag  or 
wing  and  squadron  local  exercises). 

Scalability  is  comprised  of  four  components: 

1.  Ability  to  plan  and  execute  operational  air  power  ranging  from  one  assigned  aircraft  to  all 
aircraft  needed  to  support  a  theater  scale  conflict  in  periods  ranging  from  less  than  a  day  to  an 
extended  period.  Small-scale  operations  must  be  managed  without  a  large  highly  trained 
manpower  pool. 

2.  Applicability  to  any  organization  with  an  operational  air  power  planning  and  execution  need 
from  a  small  unit  in  local  training  to  a  Joint  Forces  Air  Component  Commander  (JFACC)  staff 
with  major  theater  war  or  major  command. 

3.  Output  in  both  Management  Information  System  (MIS)  and  military  message  format.  The 
current  ATO  is  produced  in  “hard  copy”  only  for  extremely  communication-disadvantaged  users. 
Most  users  of  the  ATO  message  “pull”  it  from  a  webpage.  Current  procedure  is  to  post  it  in 
different  types  of  files  (e.g.,  MIS  files  could  include  .doc,  .pdf,  ..xls  or  military  message  file  like 
.ato). 

4.  Output  automatically  available  to  coalition  member  countries  in  both  their  required  military 
message  format  and  MIS  format  to  be  placed  on  networks  to  which  they  have  access.  In  Gulf 
War  II,  the  ATO  was  put  on  transfer  media  (floppy  disk),  placed  in  a  PC,  and  run  against  a 
Practical  Extraction  and  Reporting  Language  script  to  remove  fields  in  mission  lines  and 
paragraphs  not  releasable  to  the  coalition  member  receiving  the  message.  After  parsing,  the 
message  was  placed  on  the  appropriate  network  as  a  file  and  coalition  countries  used  their 
manpower  to  interpret  and  execute  missions  they  had  agreed  to  provide. 

The  second  requirement  for  an  Operational  Air  Power  Planning  tool  is  flexibility.  CTAPS, 
TBMCS,  and  most  systems  of  record  (SOR)  in  the  past  20  years  were  stovepipe  designed  for 
defined  input  and  output  with  a  static  process  and  algorithms  to  reach  a  predefined  goal. 
Planning  systems  in  this  century  should  attain  flexibility  through  six  characteristics: 

1.  Group  Planning-many  manual  and  semi-manual  processes  were  created  ad  hoc  to  organize 
information  for  a  cognitive  operational  air  power  plan.  The  most  important  characteristic  of  an 
Air  Power  Planning  tool  is  to  accommodate  a  large  rapidly  changing  membership  both 
physically  and  virtually  present  in  building  the  Operational  Air  Power  Plan  as  a  cognitive 
concept.  TAP  does  not  “plan.”  It  deconflicts  data  by  comparing  it  to  previously  entered  internal 
information.  In  most  cases,  the  tanker  plan  was  entered  at  the  end  of  the  planning  cycle  and  any 
conflict  would  prorogate  throughout  completed  mission  lines.  Each  “error”  would  have  to  be 
corrected  by  the  builder  of  each  mission  line  affected.  A  system  with  cognitive  ability  could 
calculate  tanker  resources,  equate  this  data  to  gallons  of  gas  for  offload,  and  allow  the  planner  to 
assess  the  requirement  for  “X”  packages  of  aircraft  in  tasking  tanker  support  before  mission  lines 
are  created. 

2.  Known  Data  Import-Computer-based  planning  tools  should,  as  directed  or  scheduled  by  the 
operator,  automatically  import  data  and  information  from  known  data  sources.  In  TBMCS,  all 


information  on  friendly  forces  is  manually  entered  and  most  of  that  data  is  in  another  computer 
system.  For  example,  Blue  Force  location  is  in  the  Joint  Operations  Planning  and  Execution 
System.  It  can  be  acquired  by  an  account  holder  requesting  an  FI  ID  report  on  aviation  units.  The 
location  of  every  base  on  earth  is  tracked  and  updated  by  Air  Mobility  Command,  but  we 
continue  to  accept  a  5%  input  error  rate  for  bases  hand  typed  into  TAP  for  each  exercise  or 
contingency. 

3.  Cut  and  Paste-  A  simple  function  such  as  “cut  and  paste”  should  be  available  to  the  operator 
to  transfer  information  and  encourage  information  exchange  from  semi-formatted  documents  (e- 
mail,  text  chat,  etc.)  to  system  data  storage  and  data  output.  In  TBMCS,  simple  activities  such  as 
printing  in  color  or  exchanging  information  from  UNIX  to  PC  can  be  excruciatingly  difficult. 
“Cut  and  paste”  might  easily  transfer  information  to  pair  a  fighter  in  one  ATO  period  to  a  tanker 
in  a  previous  one,  a  data  transfer  that  is  very  difficult  to  accomplish  now. 

4.  Pre-populated  Information-Static  or  near  static  information  should  be  pre-populated  in  the 
planning  system,  have  the  capability  to  be  reset  to  its  initial  state,  if  required,  or  amended  for 
addition  and  growth.  When  a  TBMCS  is  brought  on  line,  its  databases  are  empty,  although  the 
names  and  basic  characteristics  of  all  the  world’s  aircraft  and  munitions  are  known.  Semi-static 
information  like  the  Airfield  Digital  Aeronautical  Flight  Information  Files  that  update  airfield 
information  are  produced  every  28  days  and  should  be  incorporated. 

5.  Human  Understandable-  Input  should  be  the  same  in  style  and  function  as  the  largest  market 
share  commercial  application  in  the  home/school  environment.  Output  of  machine-readable 
military  messages  and  information  should  be  in  human  readable  fonnat.  TBMCS  implemented 
this  output  concept  by  displaying  ATO  and  ACO  messages  in  tabular  view,  but  “words”  from  the 
message  could  be  truncated  in  the  table.  Of  247  USMTF  messages  available  to  TBMCS,  only  the 
ATO  and  ACO  can  be  viewed  in  human  “friendly”  fonnat.  Identify  Friend  or  Foe  (IFF)  modes 
and  codes  to  plan  against  are  never  displayed  in  human  readable  form.  IFF  available  codes  are 
four  place  sequential  base  8  numbers  and  most  humans  understand  base  10  numbers.  Therefore, 
in  all  conflicts  and  major  exercises,  codes  assigned  and  used  have  to  be  hand  tracked.  An 
enterprise  wide  mapping  function  should  be  used  and  background  maps  should  be  similar  for 
display  of  data  to  the  human  warfighter. 

6.  Build  Military  Messages-Organizations  that  are  extremely  disadvantaged  in  communication 
capability  require  a  hard  copy  of  the  USMTF  ATO  message.  An  Operational  Air  Power  Planning 
tool  should  fill  in  fields  of  known  military  messages  and  validate  compliance  with  rules 
governing  them.  Each  of  the  messages  could  be  required  by  someone  in  the  Combined  Air 
Operations  Center.  One  example  is  the  Situational  Report.  Currently,  builders  of  this  message 
use  other  systems  and  workarounds  to  get  infonnation  in  TBMCS  to  populate  ATO  or  ACO 
message  fields.  These  messages  should  also  be  available  to  other  joint  military  nodes  on  the 
same  security  level  network. 

The  final  cornerstone  of  a  21st  century  Operational  Air  Power  Planning  tool  is  ease  of  use.  Most 
people  in  today’s  military  are  computer  savvy.  They  grew  up  with  internet,  e-mail,  text  chat, 
advance  computer  gaming,  and  other  concepts.  They  do  not  need  training  on  how  to  turn  on  a 
PC.  A  commercial-off-the-shelf  (COTS)  mind  set  must  be  brought  quickly  to  bear  in  solving 
military  operational  problems.  Ease  of  use,  in  a  military  setting,  must  incorporate  six  basic 
concepts. 

1.  Intuitive:  The  TBMCS  1.1.1  TAP  System  User  Manual  is  875  pages.  Most  of  it  defines  how 
the  operator  will  input  required  data.  Comprehensive  understanding  of  the  TBMCS  program 


down  to  network  level  can  require  2  years  of  dedicated  training.  A  newly  assigned  AOC 
crewmember,  expert  in  his  function,  should  be  intuitive  on  how  to  enter  and  manipulate  data  in 
the  Operational  Airpower  Planning  tool.  For  example,  an  expert  at  aircraft  scheduling  should  be 
able  to  sit  down  at  a  PC  client  and  start  inserting  his  information.  If  a  user  manual  is  required,  it 
should  be  no  longer  than  COTS  manuals  for  the  commercial  home/school  market. 

2.  Administrative  Simplicity:  most  SOR  are  designed,  built,  and  tested  as  standalone 
solutions.  In  the  AOC  Weapon  System,  all  computer  applications  that  deal  with  information  of 
the  same  security  level  must  operate  on  a  common  network  and,  in  many  cases,  applications 
must  be  on  the  same  physical  servers  and  clients.  System  administration  from  account  creation  to 
complex  functions  like  system  rebuild  should  be  designed  from  an  enterprise  solution  with  the 
goal  of  single  entry  of  data  and  Graphical  User  Interfaces.  Just  as  manpower  to  sustain  complex 
weapon  systems  like  F-4  fighters  was  considerably  reduced  with  maintenance  concepts  included 
in  F-16  design,  computer  applications  can  go  from  standalone  solutions  to  enterprise  solutions. 

3.  Output  for  Senior  Leadership:  Any  organization,  including  AOCs,  with  PowerPoint 
software  generally  use  it  to  convey  decision  quality  information  to  leadership.  Most  slides  are 
created  and  then  updated  for  recurrent  daily  briefings.  In  the  AOC,  the  de  facto  result  has  been 
that  each  cell/organization  produces  its  required  output  document  (ATO,  ACO,  Aerospace 
Operations  Directive)  and  a  PowerPoint  briefing  for  senior  leadership  on  that  product.  Some 
applications  in  the  AOC  incorporate  automatic  slide  building  applications  (i.e.,  Master  Air 
Attack  Plan  Toolkit  and  TBMCS  1.1.3  Accenture  Strategy  Tool),  but  these  tools  create  slides  in 
a  detenninistic  manner  and  are  not  available  to  everyone.  Anecdotal  information  from  users  is 
that  they  are  not  amenable  to  General  Officer  briefings  due  to  creative  slide  building  constraints. 
Creation  of  intra-document  links  between  components  of  a  briefing  is  a  difficult  and  time- 
consuming  task  exacerbated  when  information  is  arrayed  across  numerous  non-congruent 
security  based  classification  levels  of  networks.  The  faulty  logic  used  in  the  AOC  is  that  human 
intervention  is  necessary  if  the  semantic/creative  relationship  that  exists  between  components  of 
documents  is  to  remain  viable. 

4.  Non  Deterministic  Environment:  Microsoft  applications  are  very  successful  in  building 
tools  in  which  the  user  provides  data  but  the  milieu  remains  constant  (e.g.,  the  user  can  enter  data 
where  and  how  he  detennines  best  to  solve  his  problem  in  Excel,  the  Excel  program  does  not 
require  the  how  and  where  the  data  is  to  be  entered.  In  TBMCS,  you  can  only  enter  the  data  into 
pre-fonnatted  data  repository  slots).  One  of  the  major  challenges  affecting  systems  as  large  and 
complex  as  TBMCS  is  time  and  cost  to  update  the  data  store  (TBMCS  uses  commercial  Oracle 
and  Sybase  databases).  Data  service  layers  and  XML  tagging  allow  less  detenninistic  data 
transposition  between  application  and  databases,  but  if  a  user  needs  to  add  tables,  rows,  or 
columns  or  change  the  relationship  of  the  data,  it  must  go  back  to  the  “factory”  and  it  may  be 
years  before  the  potential  solution  is  available.  There  are  always  tradeoffs  in  designing  software 
to  be  both  robust  and  flexible.  Military  systems  dealing  with  the  “Cold  War”  monolithic  threat 
had  to  lean  toward  the  need  to  be  robust.  Military  systems  in  the  uncertainty  of  the  fragmented 
threat  of  a  modem  world  should  lean  toward  flexibility. 

5.  Effective  Human  to  Computer  Linguistics:  One  of  the  most  vexing  problems  in  interactive 
design  for  an  advanced  Command  and  Control  (C2)  node  is  when  implementing  concepts 
demonstrate  the  fundamentally  asymmetric  nature  of  the  relationship  between  humans  and 
computer  systems.  The  human  advantage  for  symmetric  interaction  is  based  on  three 
fundamental  abilities:  listening,  thinking  and  speaking.  Computer  systems  “listen”  poorly, 
“think”  some,  and  “speak”  well.  The  current  typical  application  gives  the  warfighter  system  user 


very  little  to  say  or  do  and  then  hoses  him  down  with  megabytes  of  audiovisual  extravaganza. 
This  explains,  to  some  extent,  the  style  needs  to  be  encapsulated  in  an  Operation  Airpower 
Planning  Tool  concept  design  as  an  attempt  to  balance  the  needs  of  human  warfighters  with 
computer  systems.  A  successful  model  of  human  to  computer  interaction  is  “TurboTax.”  This 
program  converts  often  bizarre  contradictory  tax  laws,  rules,  and  regulations  to  a  relatively 
simple  series  of  “computer  asked-human  answered”  questions.  There  are  other  problems  to 
consider,  but  warfighter  effectiveness  could  clearly  be  enhanced  by  expenditure  of  computer 
resources  that  balance  the  needs  of  both  man  and  machine. 

6.  Embedded  Fuzzy  Logic:  the  lack  of  fuzzy  logic  is  one  of  the  best  examples  of  a  major 
failing  of  TBMCS.  There  are  many  different  ways  to  name  an  aircraft.  In  some  fields  of  the 
USMTF  message,  the  type  of  aircraft  is  only  represented  in  predefined  patterns,  (e.g.,  you  have 
an  F16  or  an  F16A,  but  no  F-16  or  F16-A).  Other  entry  fields  are  based  on  previously  entered 
TAP  data  stores  (e.g.,  if  Fort  Drum  is  a  base  in  the  TAP  data  store,  you  can  fly  to  Fort  Drum  but 
you  cannot  not  fly  to  Ft.  Drum.  If  an  entry  for  Ft.  Drum  is  required,  the  user  has  to  go  back, 
update  the  data  store,  and  then  plan  his  mission  line).  Both  cases  require  a  user  trained  on  how  to 
enter  data  and  familiar  with  the  limitations  of  the  system.  With  embedded  fuzzy  logic,  you  type 
“Stinkbug”  and  the  F-117  symbol  populates  wherever  it  needs  to  occur.  The  next  generation 
Airpower  Planning  tool  must  have  embedded  in  its  code  the  understanding  of  the  advantages 
fuzzy  results  produced  by  the  analog  tools  of  previous  non-digital  generations  (the  SR-7 1  was 
made  by  the  non-computer  generation). 

A  new  application,  Theater  Battle  Operations  Net-Centric  Environment  (TBONE),  is  one  of 
several  tools  being  developed  to  replace  TBMCS  and  TAP  and  eliminate  well  known 
peccadilloes.  It  is  too  early  in  the  TBONE  development  cycle  to  detennine  if  it  will  become 
another  ATO  production  tool  or  a  truly  conceptual  Air  Power  Planning  tool.  As  TBONE 
continues  its  accelerated  developmental  schedule,  PowerPoint  slides  developed  by  diverse 
organizations  indicate  TBONE  is  approaching  success.  All  organizations  should  tout  their 
success.  A  recent  set  of  slides  indicate  TBONE  has  reached  70%  of  its  goals.  The  current 
Department  of  Defense  5000  series  regulation,  using  the  concept  of  spiral  development, 
encourages  fielding  software  at  the  80%  capability  level.  Sometimes,  a  software  program  is 
fielded  without  reaching  100%  of  desired  goals,  but  at  the  80%  capability  level.  This  is 
outstanding  policy  if  the  undone  percentage  is  not  critical  to  mission  accomplishment.  Undone 
percentages  of  mission  critical  requirements  can  lead  to  unsafe  conditions,  confusion  in  the 
battlespace,  and  unexecutable  taskings. 

The  most  recent  TBONE  Limited  Objective  Experiment  report  did  not  evaluate  TBONE  against 
needed  “AOC  engine”  replacement  requirements.  It  correctly  evaluated  TBONE  against  current 
available  capabilities.  Both  slides  and  reports  could  easily  place  in  the  mind  of  individuals  a  false 
impression  of  where  TBONE  is  in  its  developmental  cycle  if  they  are  not  involved  in  the  daily 
“heavy  lifting”  of  operational  C2.  In  the  future,  TBONE  may  have  slides  and  reports  showing 
99%  of  goals  or  capabilities  reached,  but  the  measurement  is  irrelevant  in  detennining  if  this 
“engine”  is  ready  to  go  and  fight  an  airpower  war.  Software  systems  should  not  put  human 
beings,  other  scarce  resources,  or  mission  success  at  unreasonable  risk  because  of  developmental 
pressures  and  timelines.  This  paper  is  to  define  the  four  key  “cylinders”  TBONE  must  have  to  be 
a  successful  replacement  to  TBMCS  and  TAP  as  the  engine  of  the  AOC,  no  matter  what 
percentage  desired  capabilities  or  goals  are  reached. 


One  of  the  main  functions  that  TAP  accomplishes  for  the  user  is  to  determine  if  a  mission  is 
flyable  or  un-flyable  equal  to  or  better  than  manual  operational3  planning.  Using  our  engine 
metaphor,  detennining  if  a  mission  is  flyable  is  top  dead  center  of  the  number  one  cylinder. 
Both  the  expert  aircrew  planner  and  the  non  aircrew  technicians  rely  on  this  function.  The  TAP 
application  key  constraint  checking  capability  concerns  associations  between  missions  -  are  the 
escorter/escortee,  tanker/receiver,  and  package  membership  consistent  in  time  and  space.  For 
example,  the  expert  planner  might  receive  the  error  message:  “Unflyable  Mission”  after  building 
a  new  mission  line.  In  most  cases,  the  “error”  would  prompt  the  user  to  review  the  planned  line 
and  see  what  caused  the  problem.  If  the  “problem”  was  a  mission  10  minutes  short  of  required 
turn  time,  the  expert  could  use  his  judgment  and  adjust  the  mission  line  as  necessary.  In  our 
example,  if  the  new  mission  line  showed  a  large  aircraft  flying  12  hours  that  had  a  6-hour  turn 
time  and  was  10  minutes  short  of  needed  time,  an  expert  operator  could  determine  the  “problem” 
insignificant  and  override  the  computer.  For  the  non  aircrew  technician,  the  Flyable/Non-flyable 
flag  highlights  when  the  expert  aircrew  planner  should  be  queried. 

The  number  two  cylinder  of  our  new  engine  is  the  ability  to  determine  if  a  mission  needs 
refueling  and,  if  so,  allow  pairing  of  that  mission  to  a  refueling  aircraft.  The  amount  of  gas 
(aviation  fuel)  aloft  and  available  drives  the  air  war.  Any  determination  of  operational 
efficiencies  relies  on  airborne  fuel  used;  any  decrease  of  capability  will  directly  extend  days  and 
hours  of  air  combat.  TAP  was  created  to  eliminate  the  manual  (less  accurate/slower)  methods  of 
determining  fuel  usage  and  help  pair  fighters  to  tankers.  TAP  is  adept  at  pairing  fighters  and 
tankers  and  detennining  approximate  fuel  needed  for  strike  missions.  It  did  straight-line 
(operational  level)  planning  and  fuel  calculations  for  each  mission  line  created.  TBONE  must 
have  the  capability  to  resolve  the  airborne  refueling  problem  with  a  high  degree  of  accuracy. 

Our  third  engine  cylinder  is  building,  at  least,  all  current  mission  types  and  mission  lines  created 
by  TBMCS  within  a  valid  USMTF  message.  The  valid  USMTF  message  is  the  legal  order.  It  is 
how  the  JFACC  directs  tactical  units  and,  in  some  cases,  communicates  with  individual  flights. 
TBMCS  builds  a  1998  and  a  2000  USMTF  message,  TBONE  builds  2000  and  2004  USMTF 
messages.  Organizations  that  are  extremely  disadvantaged  in  communication  capability  might 
only  have  a  hard  copy  of  the  USMTF  ATO  message.  Other  military  C2  organizations  and 
systems  require  valid  messages  sent  to  them  or  pulled  down  from  a  web  page.  The  TBONE  tool 
should  fill  in  fields  of  ATO/ACO  military  messages  with  valid  entries  according  to  the  rules 
governing  it.  When  reviewed  by  aircrews  flying  the  tasking  described  in  the  ATO,  the  message 
must  be  have  enough  information  to  plan  and  fly  the  mission.  Often,  in  exercises,  messages  are 
valid  by  the  rules  governing  the  message  but  fail  to  reach  “adequate  information”  criteria.  The 
third  cylinder  also  includes  the  ability  to  import  and/or  build  mission  lines  created  by  other 
Services,  nations  and  organizations  with  their  organic  C2  systems.  The  ATO  is  used  to 
coordinate  all  airpower  and  must  correspond  to  multi-community  needs. 

The  fourth  and  last  cylinder  relates  directly  to  third  cylinder.  Just  as  TBONE  must  be  able  to 
build  a  change  “zero”  message,  it  must  also  be  able  to  build  or  import  changes  (1,  2,  3... etc.)  to 
the  ATO/ACO  during  execution.  The  technical  challenge  is  to  build  valid  and  “flyable”  changes 
and  not  to  negatively  impact  the  information  used  to  build  the  following  day’s  change  “zero” 


3  In  years  past,  manual  operational  planning  was  accomplished  using  paper  rulers,  different  colors  for  various 
aircraft,  marked  with  speeds  and  approximate  fuel  flow  and  numerous  area  charts. 


message.  There  are  unwritten  “business  rules”  developed  by  military  aviation  receivers  of  the 
ATO,  besides  USMTF,  for  how  changes  should  be  created,  for  example: 

1. )  TBONE  needs  to  prevent  missions/airspaces  that  have  not  changed  from  coming  out  in  a 
change.  Undetennined  changes  drive  tactical  users  nuts  trying  to  figure  why  the  change  was  sent. 

2. )  On  the  other  hand,  if  my  mission  did  change,  the  AOC  must  reissue  the  entire  mission  and 
associated  missions  in  the  change.  If  you  fail  to  mention  a  mission  associated  tanker  (because,  in 
the  “mind”  of  the  software,  the  tanker  did  not  change),  a  tactical  user  will  not  know  if  the  tanker 
was  or  was  not  changed  or  cancelled. 

3. )  Mission  numbers  must  not  be  reassigned  from  unit  x  to  unit  y  after  the  ATO  comes  out.  Unit 
x  does  not  read  unit  y  tasking  and  won’t  figure  it  out.  The  result  is  that  you  could  have  two  units 
executing  the  same  mission.  The  ATO  must  convey  something  like  “Unit  x  Mission  1001  is 
cancelled.  Unit  y  now  has  new  mission  1001A.”  TBONE  must  work  within  the  “rules”  expected 
by  the  tactical  community. 

The  four  cylinders  of  the  AOC  engine  provide  the  Commander  the  capability  to  plan,  execute, 
and  assess  theater- wide  air  and  space  operations.  Too  often,  in  the  past,  the  staff  using  the 
provided  C2  system  spent  considerable  time,  energy,  and  effort  making  the  system  work  in 
accordance  with  system  design  criteria  and  not  in  accomplishing  the  military  goals  of  their 
commander.  If  TBONE  can  eliminate  the  notorious  eccentricities  of  TBMCS  and  TAP  and  still 
accomplish  the  goals  of  the  four  cylinders  needed  by  any  engine  of  the  AOC,  the  warfighting 
commander,  his  staff,  and  the  nation  would  be  welled  served. 

In  conclusion,  if  there  is  a  single  key  to  a  more  efficient  advanced  Operational  Airpower 
Planning  tool,  it  is  being  able  to  analyze  and  react  to  changing  military  conditions  much  more 
rapidly.  To  do  this,  Senior  Leaders,  Cell  Chiefs,  and  C2  warfighters  inside  the  AOC  need 
appropriate  and  better-organized  information  in  a  system  that  is  scalable,  flexible,  and  easy  to 
use.  Information  technology  itself  has  revolutionized  the  way  organizations  operate  throughout 
the  world.  Unfortunately,  despite  increasingly  powerful  computers  and  communication  networks 
that  span  the  globe,  many  senior  military  leaders  and  decision  makers  cannot  obtain  critical 
information  that  already  exists  somewhere  in  their  organization.  Every  day,  the  Air  Force  and 
Department  of  Defense  (DOD)  create  billions  of  bytes  of  data  about  all  aspects  of  their  work  in 
protecting  the  nation:  millions  of  individual  facts  about  military  resources,  potential  enemies, 
ongoing  operations,  and  people.  For  the  most  part,  this  data  is  locked  in  myriad  computer 
systems  and  exceedingly  difficult  to  access.  This  phenomenon  is  best  described  as  "data  rich, 
information  poor."  Experts  estimate  that  only  a  small  fraction  of  data  that  is  captured,  processed, 
and  stored  in  any  computer  enterprise  by  a  large  organization  is  actually  available  to  leaders  and 
decision  makers.  While  technologies  for  manipulation  and  presentation  of  data  have  literally 
exploded,  only  recently  have  those  involved  in  developing  Information  Technologies  (IT) 
strategies  for  large  organizations  concluded  that  large  segments  of  senior  leadership  are 
"information  poor."  The  three  cornerstones  (scalability,  flexibility,  and  ease  of  use)  of  an 
operational  concept  for  strategic  advancement  of  a  large  IT  planning  system  are  inextricably 
linked.  If  only  some  concepts  of  one  or  two  cornerstones  are  accomplished,  it  will  be  easy  to 
spend  billions  to  produce  a  tool  capable  of  building  an  ATO,  but  it  will  not  be  a  tool  that  helps 
humans  build  the  cognitive  conceptual  Operational  Airpower  Plan. 
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The  Combat  Air  Power  Today 
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Planning  systems  of  yester-year 


Planning  is  always  best  as  a  group  effort 
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Easy  things  should  be  easy  to  do! 


The  right  information  at  the  right  time! 


Sometimes  understanding  is  hard 


Someone  will  always  need  a  hard  copy  message 


Knowledge  is  our  core  power 


Simplicity  is  the  goal 


More  “boxes”  don’t  always  make  our  lives  easier 


Leaders  must  decide! 


The  “information”  not  the  milieu  is  important 


I  am  warm  and  fuzzy  and  my  girlfriend  says  I  still  don’t  make  sense! 


Conceptual  Air  Power  planning  requires  scalability,  flexibility,  and  ease  of  use 
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